There are applications that need to process large amounts of data, i.e. several hundreds of MBs, stored in the form of binary large objects (BLOBs). Typically the data relates to (medical) images, sound, movies, and multi-media files. When one or more such BLOBs are to be modified, the well-known ACID (atomicity, consistency, isolation, durability) requirements must be fulfilled:                Atomicity: Either all data in all involved BLOBs is modified or no changes are done. It must never happen that only some of the modifications are applied. If this cannot be guaranteed, the resulting mix of modified and unmodified data may be unusable.        Consistency: It must be possible to simultaneously modify multiple BLOBs. If this cannot be guaranteed, there would frequently be times, where some BLOBs have been modified and others are still waiting for modification; such a mix of data may be unusable.        Isolation: Two programs must not modify the same BLOB or overlapping sets of BLOBs at the same time. If this cannot be guaranteed, the resulting mix of data from different modifications may be unusable.        Durability: When the modifications are completed, they must be stored on disk (not just in a cache memory) so that the modifications are not lost if the storage system or the computer stop working afterwards. If this cannot be guaranteed, the user may believe the modifications have been made, when they are actually not saved.        
It should be possible to fulfil this requirement based on common off-the-shelf (COTS) software, i.e. standard file system and database software, using well-known application programming interfaces such as Posix file system functions and SQL statements for database operations.
Moreover, an additional requirement is that the identity of a file in a file system must be preserved, i.e. it must not be lost. For example, if a backup of a file is made, the file is modified and then the backup should be restored. In this case it must be possible from just looking at the file names in the backup and in the file system, which file on backup is related to the modified file.
In standard file systems, such as DOS FAT, NTFS, Linux ext2, etc. simple operations such as “create a file”, “update the contents of a file”, “rename a file”, “delete a file” are possible. These are not sufficient to fulfil the ACID-requirements. Journaling file systems, such as e.g. NTFS in certain configurations or Linux ReiserFS, fulfil the ACID-requirements for single files, but not for sets of files. Moreover, even though file systems typically are capable of storing BLOBs, transactions on BLOBs are typically not supported. It has been suggested to simply store BLOBs in a file system and do without transactions on the BLOBs.
Standard database systems, such as MS SQLserver or Oracle, typically provide functionality for fulfilling the ACID-requirements, but they are not optimized for operating on sets of large files. It is well-known that performance in standard database systems becomes a problem with large data sized. Most standard databases provide some support for transactions involving BLOBs that can have sizes of up to tens or hundreds of MB, but they are not optimized for transactions involving hundreds of MB. This usually makes the standard databases unusable for managing BLOBs.